Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9610/000106_owner-urn-ietf _Thu Oct 24 16:12:16 1996.msg

Internet Message Format | 1997-02-19 | 4KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA18613 for urn-ietf-out; Thu, 24 Oct 1996 16:12:16 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA18608 for <[e-mail]>; Thu, 24 Oct 1996 16:12:11 -0400
Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA29401  (mail destined for [e-mail]); Thu, 24 Oct 96 16:12:04 -0400
Received: from ifi.unizh.ch by josef.ifi.unizh.ch
          id <[e-mail]>; Thu, 24 Oct 1996 22:12:00 +0100
Subject: Re: [URN] Pre release of URN Syntax document....
To: [e-mail]
Date: Thu, 24 Oct 1996 22:11:59 +0100 (MET)
Cc: [e-mail], [e-mail]
In-Reply-To: <"josef.ifi..740:21.09.96.21.00.14"@ifi.unizh.ch> from "Ryan Moats" at Oct 21, 96 03:04:20 pm
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2228
From: Martin J Duerst <[e-mail]>
Message-Id: <"josef.ifi..921:24.09.96.21.12.01"@ifi.unizh.ch>
Sender: [e-mail]
Precedence: bulk
Reply-To: Martin J Duerst <[e-mail]>
Errors-To: [e-mail]

Ryan Moats wrote:

>On Mon, 21 Oct 1996 20:36:58 +0200 (MET DST), Patrik Faltstrom wrote:
>>
>>On Mon, 21 Oct 1996, Martin J Duerst wrote:
>>
>>> The other big problem is equivalence. For Unicode, character equivalence
>>> is in some cases not the same as codepoint equivalence. Charecter
>>> equivalence is well defined, but there is currently no standard
>>> for normalization.
>>
>>What exists are the decomposition rules for Unicode. Those are well defined.

Yes, but they define equivalence, not normalization. So every
instance wanting to compare two urns would have it included.
With normalization, it would only be those instances that
"produce" urns, i.e. where resources are named or where
urns are entered into a computer.

>>> This does not concern things such as case,
>>> where the user can easily distinguish lower case and upper case,
>>> but cases such as A-with-Grave, which can be encoded both as
>>> one single codepoint and as the sequence A, Grave.
>>
>>The casing is also defined in the Unicode spec.

Yes, but it is clearly NSS-dependent, and language-dependent
in addition. And in contrast to such things as the A-grave
story, no user will be surprised that a lower case and an
upper case character are not the same.

>>> Another problem that should be considered are bidirectionality
>>> for Hebrew and Arabic.
>>
>>It should be defined, just like in MIME, that characters are
>>stored in the order they are stored, not displayed. (At least
>>I remember that we discussed this with display order in the
>>MIME community in an interesting meeting faaaar back in time,
>>which was ended by looking at some example where two hebrew
>>users, using the same computer, was using different display
>>order...).
>
>I agree with Patrik.  Regardless of glyph direction order, NSS octets
>are in order of presentation ie. (for left->right, left most character first,
>for right->left right most character first, etc.)

It's not as easy as that. Are Bidi control characters allowed in
urns? Overrides (overriding implicit reordering and thus
basically specifying presentation order) are very convenient
e.g. for part numbers, and there are quite some similarities
between part numbers and urns.


Regards,    Martin.